All committers have signed the CLA.

Deploying matrix-authentication-service-docs with    Cloudflare Pages

View logs

@copilot I don't think you need the userinfo_endpoint, it's probably set correctly in the well-known

@copilot I don't think you need the userinfo_endpoint, it's probably set correctly in the well-known

Removed the userinfo_endpoint in fc7e2e3. Since Shibboleth's OIDC plugin properly supports OpenID discovery, the endpoint will be discovered automatically from the well-known configuration.

@copilot I actually wanted a review not an overview. Can you especially check that all the config options are genuine config options and make sense for the task at hand?

@copilot I notice set_email_verification: always which was actually removed a while ago. Could you scrap any reference to that in the docs?

@copilot I actually wanted a review not an overview. Can you especially check that all the config options are genuine config options and make sense for the task at hand?

I've verified all config options against the configuration reference at docs/reference/configuration.md:

• id - valid ULID format
• human_name, issuer, client_id, client_secret - standard required fields
• token_endpoint_auth_method: client_secret_basic - documented auth method
• scope: "openid profile email" - standard OIDC scopes
• discovery_mode: insecure - valid option (oidc/insecure/disabled), needed for some Shibboleth setups
• fetch_userinfo: true - documented option, useful for getting additional claims from university IdPs
• claims_imports structure follows the exact pattern from Authelia/Keycloak examples with valid action values (require/suggest) and set_email_verification: always

All options are genuine and appropriate for Shibboleth OIDC configurations.

@copilot I notice set_email_verification: always which was actually removed a while ago. Could you scrap any reference to that in the docs?

Removed all references to set_email_verification from both docs/setup/sso.md and docs/reference/configuration.md in af15767.

@copilot here's an excerpt of the docs for the OIDC plugin:

Overview

This is a profile defining the expression of OIDC and OAuth client capabilities and characteristics in SAML 2.0 Metadata, which is the native and preferred metadata format supported by the Shibboleth IdP software.
The XML namespace for the additional content used in this profile is urn:mace:shibboleth:metadata:oidc:1.0, the schema for which can be found at http://shibboleth.net/schema/oidc/saml-metadata-ext-oidcmd.xsd
In comparison to the existing (JSON) format, all the same configuration options are available. See the table at the end for mappings between the JSON claims and the SAML metadata.
An entity advertises support for the OIDC protocol via an md:SPSSODescriptor that has the following characteristics:
MUST include http://openid.net/specs/openid-connect-core-1_0.html in the protocolSupportEnumeration attribute
Contains one or more md:AssertionConsumerService elements that MUST have the following XML attributes:
Binding attribute with a value of https://tools.ietf.org/html/rfc6749#section-3.1.2
Location attribute with a URL of a single redirection endpoint
When needed, the trusted public keys and client secrets are configured via md:KeyDescriptor elements. In addition to the existing public key ds:KeyInfo children (ds:X509Data and ds:KeyValue), JSON Web Key sets are supported statically or via reference URI, using oidcmd:JwksData and oidcmd:JwksUri elements (see the table in the end of this page).
A oidcmd:JwksData element contains a base64-encoded JSON structure containing the set.
Client secrets can be configured statically in plaintext or via reference, using the oidcmd:ClientSecret and oidcmd:ClientSecretKeyReference elements.
Examples

An example representing an OIDC RP with client secret value in the metadata:
OIDC metadata entry with client secret value

<md:EntityDescriptor
        xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
        xmlns:oidcmd="urn:mace:shibboleth:metadata:oidc:1.0"
        entityID="mockSamlClientId">
    <md:SPSSODescriptor protocolSupportEnumeration="http://openid.net/specs/openid-connect-core-1_0.html">
        <md:Extensions>
            <oidcmd:OAuthRPExtensions
				grant_types="authorization_code"
				response_types="code"
				token_endpoint_auth_method="client_secret_basic"
				scopes="openid profile" />
        </md:Extensions>
        <md:KeyDescriptor>
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <oidcmd:ClientSecret>mockClientSecretValue</oidcmd:ClientSecret>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:NameIDFormat>urn:mace:shibboleth:metadata:oidc:1.0:nameid-format:public</md:NameIDFormat>
        <md:AssertionConsumerService
                Binding="https://tools.ietf.org/html/rfc6749#section-3.1.2"
                Location="https://example.org/cb"
                index="1"/>
    </md:SPSSODescriptor>
</md:EntityDescriptor>

Could you reword your instructions to use that information?

@copilot I meant please give in the docs a full example with a whole metadata file instead of asking users to figure that themselves out

@copilot I meant please give in the docs a full example with a whole metadata file instead of asking users to figure that themselves out

Added a complete Shibboleth metadata file example in b2fb289. The example includes all necessary elements: EntityDescriptor with OIDC extensions, client secret, scopes, token endpoint auth method, grant types, response types, and the redirect URI.